昨天，我把一個問題算得更清楚：即使自己的 140 筆未知活動全部取得支持，也只能讓固定外部群體中的最差位置改善一格。接下來，若想繼續縮小不確定性，就得處理外部資料中的未知紀錄。
今天選擇的是距離邊界最近的外部帳戶。它的目標活動上界是 1,127，而我的下界是 1,088，兩者相差 39。這個差距讓每一筆有完整依據的排除，都有可量化的意義。
最後，我取得一條新的官方查證路徑，找到四筆活動的完整署名證據。在新增的署名連接詞解析規則下，四筆可以轉為條件式排除，這個帳戶的上界是 1,123，距離打平還差 35。
這項解析擴充了既有文字相容規則，因此另列為敏感度層。主結果維持原規則與 1,127 上界；新的證據、解析假設與試算差異都有各自的位置。
同一天，我也把接下來九個有明確來源 ID 的候選實際查完，結果全是 HTTP 404。另外，一次精確錄音 ID 查詢雖然成功，卻沒有解決既有的身分衝突。這些結果沒有帶來新的排除，讓我能更具體說明剩下的缺口。
一個 ID，可能指向不同層級
外部紀錄來自保留下來的 ListenBrainz 活動。其中一些經由 Last.fm 匯入，帶有 lastfm_track_mbid。
不能看到這個欄位，就直接把它當成 MusicBrainz 的 recording ID。
在 MusicBrainz 裡，release track 是某個發行版本中的曲目；recording 則是它指向的錄音實體。同一段錄音可能出現在不同發行版本中，曲目與錄音也可以有不同的顯示署名。
先前的查證已經找到一首合作曲的 recording 關聯，但來源署名與錄音署名的寫法不同，因此仍保留未知。來源寫的是兩個完整藝人名字，中間使用 X；錄音署名則使用 with。
只把文字換成同一種連接詞，還不足以做排除。我要確認的是：這個來源 ID 指向哪個 track、它連到哪個 recording，以及兩者的完整藝人署名是否一致。
直接查 track 所屬的 release
今天使用 MusicBrainz 官方 API 支援的 release browse，直接傳入來源自行提交的 track ID：
/ws/2/release?track=<來源 track ID>&inc=recordings+artist-credits&fmt=json
這條路徑與先前的搜尋索引查詢不同，也沒有改用曲名挑選相似結果。回應中必須出現同一個 track ID，才能沿著它取得 recording。
今天分兩批，共查了十五個精確 track ID，每個只查一次：
結果 精確 ID 數量 處理方式
找到精確 track 與 recording 關聯 1 繼續核對完整署名
HTTP 404 14 保持未知
歧義結果 0 沒有需要選取的候選
請求或回應保存失敗 0 本次沒有傳輸失敗

第二批的九個 ID，對應最近邊界帳戶的九筆未知活動，另有一筆在其他固定帳戶共用其中一個 ID。既有候選已具備完整錄音署名，來源名字、曲名及藝人 ID 也符合原規則，缺少的是來源 ID 到錄音的精確連結。
九次查詢都收到完整的 HTTP 404 回應，沒有取得這條連結。因此這十筆活動仍是未知。
查無資料不代表這筆活動不是目標藝人，也不代表使用者沒有播放過它。十五個 ID 中的十四個沒有提供可用的關聯證據，對應活動的分類不變。這是查詢路徑目前無法補上的缺口，不能當成負面署名證據。
四筆排除，需要哪些完整證據？
成功的回應保留了完整的 12,614 bytes，內容長度與回應標頭一致。查詢的 track ID 在回應中只有一個精確匹配，該 track 明確連到一個 recording。
更關鍵的是，track 與 recording 都提供完整的 artist-credit：兩個藝人 ID 相同，順序也相同，沒有未知藝人或 Various Artists 這類不具體的實體。來源曲名亦與該 track、recording 相符。
這次新增的文字相容規則很有限：來源署名必須完整包含這些藝人的全名、順序相同，名字之間只能使用列明的合作連接詞。整段文字必須剛好解析完畢，不能剩下額外藝人或未處理的文字。
因此，只有第一個藝人的名字、交換順序、模糊縮寫、額外文字，或能解析成兩種組合的署名，都會保持未知。來源另外提交的藝人 ID 若與完整署名衝突，也不接受。
這是一個有明確範圍的來源文字相容判斷。MusicBrainz 沒有替所有 X、with 或 & 寫法作出普遍等價保證。
在固定資料裡，有四筆活動使用這個精確 track ID，並通過上述核對。完整 recording 署名中不包含目標藝人，所以在接受新增連接詞解析的條件下，四筆可以從未知轉為排除。
這裡的「完整」指的是 MusicBrainz 的完整藝人署名列表，並非完整演出人員名單。排除也仍以來源所聲稱的 track、recording 身分成立為條件；它沒有獨立證明那次活動真正播放的是哪段錄音。
新規則另列，主結果保留
既有 policy 已經把排除限於 recording 的署名藝人，而且所有比較都以來源所聲稱的錄音身分成立為條件。今天仍然維持這些限制。
擴充的是來源文字相容判斷：以前使用保守正規化後的完整名字、別名或完整合併署名；現在另外試算「全部完整名字、相同順序、有限連接詞」的解析。
我把這項解析設為明確啟用的獨立敏感度層。既有 strict 主結果的資料與規則保留，敏感度不能放進主結果欄位，也與服務端自動配對的敏感度分開。
最近邊界的外部帳戶 kenrick95，兩種規則下的結果如下：
指標 既有主結果 新增連接詞敏感度
確認目標活動 157 157
條件式排除 805 809
未知活動 970 966
目標活動可能上界 1,127 1,123

上界的計算仍是「確認目標活動＋未知活動」：
既有主結果：157 + 970 = 1,127
連接詞敏感度：157 + 966 = 1,123
我的八月 UTC YouTube Music 資料仍是 2,215 筆活動，其中 1,088 筆確認、987 筆排除、140 筆未知，目標活動範圍維持 1,088–1,228。
在固定保留資料內，兩個層的條件式位置區間相同：
比較群體 本人＋外部帳戶 主結果 連接詞敏感度
原本固定的 25 個正值帳戶 26 2–13 2–13
全部固定的 35 個帳戶 36 2–15 2–15

原因很直接：1,123 仍然高於我的下界 1,088，所以這個帳戶仍可能在我前面。
接受新增解析時，打平的門檻較小：
既有主結果：1,127 − 1,088 = 39
連接詞敏感度：1,123 − 1,088 = 35
在連接詞敏感度層，接下來若只改變其中一方，並保持另一方不變，再取得 35 筆有依據的外部排除，或 35 筆本人未知轉為確認目標活動，就能打平這個邊界。既有主結果的門檻仍是 39。位置計算使用嚴格大於；打平不會多算一個在前面的帳戶。
這些是所需證據量，並不是預測接下來一定能找到多少筆。
完整署名相同，錄音身分仍可能衝突
接著，我檢查最近邊界帳戶剩下的 219 筆錄音 ID 衝突。141 筆的來源 ID 已查證為 recording，另有 78 筆已取得精確的 track 到 recording 關聯；來源與服務端候選的署名資料都已保留。
問題是兩邊指向不同的錄音 ID。即使藝人與曲名相同，也不能直接刪掉其中一邊。現場版可能來自不同演出，同名曲目可能有不同版本；保留資料中也確實出現這些差異。
既有官方轉址資料沒有建立這 219 筆來源與服務端候選的等價關係。我選出其中一組尚未直接查過服務端 recording ID、也沒有已知版本標示差異的八筆活動，補查一次精確錄音端點。
回應是完整 HTTP 200，但回傳的仍是服務端候選自己的 ID，沒有轉到來源錄音。因此八筆活動仍保留身分衝突。查詢成功只代表取得這個實體的資料，不能自動把兩個錄音當成同一個。
目前沒有足以接受的新別名或合併證據。若日後取得官方明確轉址，仍需通過原本的來源曲名、藝人與完整署名核對，才可能改變判定。
今天縮小的是哪一種不確定性？
把第二批查詢納入後，全部 124,265 筆固定外部紀錄在原規則與獨立連接詞敏感度下分別重算，分類都與第一批結果一致。敏感度層與主結果仍只有上述四筆分類不同，其他 124,261 筆相同：
外部分類 既有主結果 連接詞敏感度
確認目標活動 6,379 6,379
條件式排除 58,364 58,368
未知活動 59,522 59,518

原本的 25 個正值帳戶與 10 個觀測零值帳戶保持固定，沒有因為新結果重新挑選群體。分析結果及 JSON、CSV、HTML 輸出會分別標示主結果與新增敏感度，保留上界差異與條件。
目前能比較的仍是八月 UTC 視窗裡保留下來的活動。本人只有 YouTube Music；朋友的 Spotify 是另一個主體，不能補成本人的聆聽資料。
實際播放時長 played_ms 仍是 null。不同來源的合格播放是否等價、完整歷史是否取得，以及全球母體與全球位置，都還沒有建立。
今天取得四筆活動可追溯的完整署名證據，算出新增文字解析條件對外部上界的影響，也實際查完九個來源 ID，確認它們目前不能補上精確連結。另一次錄音查詢沒有解決八筆身分衝突，所以沒有再縮小上界。
既有主結果仍是 1,127，連接詞敏感度仍是 1,123，位置區間沒有改善。後續需要的證據也更明確：能綁定來源 ID 的錄音關聯，或能解決兩個錄音 ID 衝突的官方等價證明。每筆判定都要保留來源身分、署名範圍與採用的規則。